test(e2e): cover a real adapter with a mocked Imgur API - #1520

Runs a complete offline-demo -> offline-demo transfer against the packaged
demo-server jar and asserts that the exported payload actually arrives.
One command, no provider credentials, no local JDK and no local Python:

    ./e2e/run.sh

Three services in the root compose file, two of which share the repo's
single Dockerfile. No new Dockerfile, no build.gradle, no settings.gradle
entry, no Java.

Also renames the existing `test` service to `gradle`. It was confusingly
named: it runs the Gradle build, while the service that actually runs tests
is a different one. Developer.md had the tell -- `docker compose run --rm
test test --tests SomeTest`, service name and Gradle task colliding on one
word. `gradle` is exact, since the service's ENTRYPOINT is ./gradlew. The
name `test` is deliberately left unused rather than reassigned to the pytest
service: it is documented and hardcoded in docker-build.yml, so a `test`
that survived but meant something else would silently run the e2e suite for
anyone with the old command in their fingers, and pass. It now fails with
"no such service". Developer.md and docker-build.yml are updated to match,
and a stale claim that the root Dockerfile pins gradle:8.10.2-jdk11 is
corrected -- it pins eclipse-temurin:11-jdk-jammy.

The jar is built through the `gradle` service, whose ENTRYPOINT is already
./gradlew, so arguments pass straight through. That keeps the pinned Gradle
6.9.2 / JDK 11 toolchain single-sourced and reuses the warm gradle-cache
volume, which a `docker build` stage could not mount. shadowJar has no path
to copyWebApp, so no Node or Angular toolchain is involved.

`dtp` overrides the image entrypoint to run `java -jar` on that shadowJar,
so the harness exercises the real packaged artifact including its
mergeServiceFiles() META-INF/services merge. It deliberately defines no
image of its own: the repo publishes no server image today, so the harness
pins a contract -- an API on 8080 plus a readable log stream -- that a
future image can satisfy by replacing three keys on one service.

Completion is read from the server log because there is no alternative.
TransferJob.state is a hardcoded CREATED with no getter, so Jackson never
emits it and GET /api/transfer/{id} reports no progress at all.

Note that "Finished processing ... with 0 error(s)" is necessary but not
sufficient: the count is copier.getErrors().size(), so a job that never
copied anything reports zero too. Failure is therefore detected from SEVERE
lines naming the job -- a clean run emits none -- and the delivered payload
is asserted separately from job completion. Both assertions were verified
by deliberately breaking them.

CI runs the harness non-blocking to begin with, uploading the server log as
an artifact whether the run passes or fails.

ImgurTransferExtension hardcoded the API root and ImgurOAuthConfig
hardcoded the authorization and token endpoints, so pointing the adapter
at a staging environment or a test double meant rebuilding it.

Both now read from config/imgur.yaml on the classpath, falling back to
Imgur's own endpoints when no file is present:

    serviceConfig:
      baseUrl:  https://api.imgur.com/3
      authUrl:  https://api.imgur.com/oauth2/authorize
      tokenUrl: https://api.imgur.com/oauth2/token

This follows the convention Flickr, Deezer and Synology already use for
other per-service settings; Imgur had simply not adopted it. Both the
exporter and the importer already took baseUrl as a constructor
parameter, so only the extension-level constants needed to change.

One asymmetry worth noting for review: ImgurOAuthConfig calls the static
TransferServiceConfig.getForService rather than taking an injected
instance, because OAuth2ServiceExtension is never handed a
service-scoped one the way WorkerModule hands one to a TransferExtension.

Behaviour is unchanged when no config/imgur.yaml is on the classpath,
which is the case for every distribution in this repo today.

Adds the first tests for either class.

The harness so far only ran offline-demo -> offline-demo: a fixed string
exported by a ten-line exporter and printed by a System.out.println
importer. That proves the machinery -- job creation, auth, worker claim,
copier, importer -- and nothing about a data path.

Adds an Imgur -> Imgur suite driving the real, unmodified
ImgurPhotosExporter and ImgurPhotosImporter against a WireMock stand-in
for api.imgur.com. A green run now covers a real OAuth2 token exchange,
pagination on two independent axes, sub-resource recursion, an image
byte round trip through LocalTempFileStore, and the album-id mapping
IdempotentImportExecutor maintains across copy iterations.

Each adapter gets its own freshly started dtp container. LocalJobStore
keeps jobs in private static maps and LocalTempFileStore keeps files on
disk, and nothing clears either between jobs, so a shared server would
make isolation a matter of luck and ordering. run.sh loops over adapters,
runs all of them even when one fails, and captures per-adapter logs and
mock request journals. A cold JVM per adapter costs about 17 seconds.

The mock URLs reach the adapter through a classpath-prepended directory:
config resolution is classpath-only and first-match-per-filename, so dtp
now runs `java -cp /workspace/e2e/config:<jar> SingleVMMain` rather than
`java -jar`, which ignores -cp. e2e/config holds only files the jar does
not ship, so it is inert for every other adapter.

Two assertions in this suite were initially vacuous and are recorded in
e2e/README.md so the next person does not repeat them:

  - Comparing delivered bytes against the fixture the mock serves makes
    the fixture its own oracle; corrupting it corrupts both sides. The
    assertion still proves each distinct fixture arrived exactly once,
    unmodified, but its negative check has to break the pipeline rather
    than the fixture.
  - Asserting that page 1 was requested proves nothing, because the
    exporter requests page N+1 whenever page N is non-empty. It now
    asserts page 2, the first request that proves page 1 had content.

Verified by hand, since no workflow runs on a stacked PR: both adapters
green together and standalone, `gradle check` green, and four negative
checks confirming the assertions bite.